USB specification was published in 1996 to provide an easy and economical method for connecting all kinds of peripheries with PCs., and has become a main interface for printers, scanners and CD burners thereafter. In year 2000, in addition to the full-speed mode (FS) of 12 Mbps and the low-speed mode (LS) of 1.5 Mbps for the USB 2.0 interface, a high-speed mode (HS) of 480 Mbps was provided for increasing the USB transmission speed by forty times of the original speed that enables the USB interface to become more suitable for high-performance peripheries, such as high-volume storage device, digital video camcorder, etc. Nowadays, the USB specification has stepped into an advance level to offer more services for mobile devices. In December of 2001, a supplement to the USB 2.0 specification had been issued to define the theories of mechanism, electrics, and communication protocol, etc. for enabling the USB interface to be applied onto the mobile devices.
The USB transfers signal and power over a four-wire cable. The signaling occurs over two wires on each point-to-point segment. For an high-speed external device that requires great bandwidth, the USB interface will adopt the full-speed mode of 12 Mbps for the transmission, on the other hand, for a low-speed external device, the USB interface will adopt the low-speed mode of 1.5 Mbps for the transmission. The USB interface can automatically detect and switch between the HS mode and the LS mode dynamically according to the external device connected therewith. USB interface is a serial bus for primitives which is similar to the serial bus for the token-ring or the primitives of the fiber distributed data interface (FDDI). The controller of the USB interface broadcasts commands for checking whether the address of commands of the equipment connected to the serial bus matches with that of the USB interface or not through receiving/transmitting data of the host. Additionally, the USB interface manages power of the serial bus by way of append/restore operation. The USB physically interconnected is a tiered star topology, consisting of three basic parts: host, hub and device.
There is only one host in any USB system. The USB interface to the host computer system is referred to as the host controller. The host comprises a host controller and a root-hub where the host Controller may be implemented in a combination of hardware, firmware, or software, which is capable of controlling the data transmission over the USB system, and the root hub is integrated within the host by connecting to the host controller to provide one or more attachment points.
A hub is a USB device that provides additional connections to the USB and is capable of providing power management and malfunction detection/restoration to the USB devices connected to the same. Each USB segment provides a limited amount of power over the cable. The host supplies power for use by USB devices that are directly connected. In addition, any USB device may have its own power supply. USB devices that rely totally on power from the cable are called bus-powered devices. In contrast, those that have an alternate source of power are called self-powered devices. A hub also supplies power for its connected USB devices. The specification of USB protocol defines that a USB frame is produced per millisecond, and a USB device can transmit and receive one transaction in each frame. A transaction is consisted of a plurality of packets, and a transmission is completed with at least one transaction for transferring a series of meaningful data. Herein a transmission is the same as a report. The USB supports functional data and control exchange between the USB host and a USB device as a set of either uni-directional or bi-directional pipes. USB data transfers take place between host software and a particular endpoint on a USB device. Such associations between the host software and a USB device endpoint are called pipes. In general, data movement though one pipe is independent from the data flow in any other pipe. A given USB device may have many pipes. As an example, a given USB device could have an endpoint that supports a pipe for transporting data to the USB device and another endpoint that supports a pipe for transporting data from the USB device. The USB architecture comprises two basic types of data transfers, i.e. control transfer and interrupt transfer. The Control transfer is used to configure a device at attach time and can be used for other device-specific purposes, including control of other pipes on the based on demand and the most general, which is used mainly for transferring message-type data. The interrupt transfer is used for characters or coordinates with human-perceptible echo or feedback response characteristics, wherein a small, limited-latency transfer to or from a device is referred to as interrupt data and such data may be presented for transfer by a device at any time and is delivered by the USB at a rate no slower than is specified by the device, which is adaptable for transferring stream-type data. Interrupt data typically consists of event notification, characters, or coordinates that are organized as one or more bytes. An example of interrupt data is the coordinates from a pointing device. Although an explicit timing rate is not required, interactive data may have response time bounds that the USB must support.
Data transaction between USBs is represented as report of data transfer, and the report descriptor is used for illustrating the usage of the report. There are three kinds of report: the input report, the output report and the feature report. The interrupt in pipe can only be used for transmitting the input report, the interrupt out pipe can only be used for transmitting the output report, and the control pipe can be used for transmitting all the input report, the output report and the feature report. The end point descriptor may announce what types of pipes are used for the end point. Descriptor is used for illustrating the usage of the transferred data which is meaningless by itself, and thus the kind of control specified by the descriptor can be performed. For example, buttons, indicating lights and displacements of x-axis and y-axis are generally referred as control, and the statuses of the buttons and the indicating lights or amount of displacement of x-axis and y-axis are referred as data. The report descriptors with respect to the corresponding controls are mapped one-on-one with the data by which data can be controlled accordingly.
There is only one host for each USB. The major layers of a host consist of the following:    (1) USB bus interface: The USB bus interface handles interactions for the electrical and protocol layers. From the interconnect point of view, a similar USB bus interface is provided by both the USB device and the host, as exemplified by the Serial Interface Engine (SIE). On the host, however, the USB bus interface has additional responsibilities due to the unique role of the host on the USB and is implemented as the host controller. The host controller has an integrated root hub providing attachment points to the USB wire.    (2) USB System: The USB System uses the host controller to manage data transfers between the host and USB devices. The interface between the USB System and the host controller is dependent on the hardware definition of the host controller. The USB System is also responsible for managing USB resources, such as bandwidth and bus power, so that client access to the USB is possible.    (3) Client: The client layer describes all the software entities that are responsible for directly interacting with USB devices. When each device is attached to the system, these clients might interact directly with the peripheral hardware. The shared characteristics of the USB place USB System Software between the client and its device; that is, a client cannot directly access the device's hardware.In addition, the USB System has three basic components as following:    (1) Host Controller Driver: The Host Controller Driver (HCD) exists to more easily map the various Host Controller implementations into the USB System, such that a client can interact with its device without knowing to which Host Controller the device is connected. The USB Driver (USBD) provides the basic host interface (USBDI) for clients to USB devices. The interface between the HCD and the USBD is known as the Host Controller Driver Interface (HCDI). This interface is never available directly to clients and thus is not defined by the USB Specification. A particular HCDI is, however, defined by each operating system that supports various Host Controller implementations.    (2) USB Driver: The USBD provides data transfer mechanisms in the form of I/O Request Packets (IRPs), which consist of a request to transport data across a specific pipe. In addition to providing data transfer mechanisms, the USBD is responsible for presenting to its clients an abstraction of a USB device that can be manipulated for configuration and state management. As part of this abstraction, the USBD owns the default through which all USB devices are accessed for the purposes of standard USB control. This default pipe represents a logical communication between the USBD and the abstraction of a USB device.    (3) Host Software: In some operating systems, additional non-USB System Software is available that provides configuration and loading mechanisms to device drivers. In such operating systems, the device driver shall use the provided interfaces instead of directly accessing the USBDI mechanisms.
The USB is a polled bus. The Host Controller initiates all data transfers. All bus transactions involve the transmission of up to three packets. Each transaction begins when the Host Controller, on a scheduled basis, sends a USB packet describing the type and direction of transaction, the USB device address, and endpoint number. This packet is referred to as the “token packet.” The USB device that is addressed selects itself by decoding the appropriate address fields. In a given transaction, data is transferred either from the host to a device or from a device to the host. The direction of data transfer is specified in the token packet. The source of the transaction then sends a data packet or indicates it has no data to transfer. The destination, in general, responds with a handshake packet indicating whether the transfer was successful. Field formats for the token, data, and handshake packets in the USB specification are defined using a 4-bit Packet Identifier (PID). An endpoint is a uniquely identifiable portion of a USB device that is the terminus of a communication flow between the host and device. Each USB logical device is composed of a collection of independent endpoints.
In the present product design, FIFO is the most general form used to construct endpoints due to that the essence of FIFO being able to contain a packet. Therefore, Each logical device has a unique address assigned by the system at device attachment time. Each endpoint on a device is given at design time a unique device-determined identifier called the endpoint number. Each endpoint has a device-determined direction of data flow. The combination of the device address, endpoint number, and direction allows each endpoint to be uniquely referenced. Each endpoint is a simplex connection that supports data flow in one direction: either input (from device to host) or output (from host to device).
All USB devices are required to implement a default control method that uses both the input and output endpoints with endpoint number zero, i.e. Endpoint-0. The USB System Software uses this default control method to initialize and generically manipulate the logical device (e.g., to configure the logical device) as the Default Control Pipe. The Default Control Pipe provides access to the device's configuration information and allows generic USB status and control access. The endpoints with endpoint number zero are always accessible once a device is attached, powered, and has received a bus reset. Functions can have additional endpoints as required for their implementation. Low-speed (LS) functions are limited to two optional endpoints beyond the two required to implement the Default Control Pipe. Full-speed (FS) devices can have additional endpoints only limited by the protocol definition (i.e., a maximum of 15 additional input endpoints and 15 additional output endpoints). A hub device can detect a supported transfer rate. It is known that USB interface implements differential data output depending on two signal wires which are D+ and D−. Thus the device recognizes a supported transfer rate via a pull-up state of the two signal wires. While the D+ signal being pulled up, it represents the FS mode; otherwise, D− signal being pulled up represents the LS mode. In this regard, when the device is being attached to a connecting port of a USB hub, the hub may detect the transfer rate of the device. Moreover, the transfer category and the rate thereof are provided in the max payload size field, that is, the size of the FIFO.
The USB supports functional data and control exchange between the USB host and a USB device as a set of either uni-directional or bi-directional pipes. USB data transfers take place between host software and a particular endpoint on a USB device. Such associations between the host software and a USB device endpoint are called pipes. In general, data movement though one pipe is independent from the data flow in any other pipe. A given USB device may have many pipes. As an example, a given USB device could have an endpoint that supports a pipe for transporting data to the USB device and another endpoint that supports a pipe for transporting data from the USB device. The USB architecture comprehends four basic types of data transfers:    (1) Control Transfers: Control data is used by the USB System Software to configure devices when they are first attached. Other driver software can choose to use control transfers in implementation-specific ways. Data delivery is lossless.    (2) Bulk Data Transfers: Bulk data typically consists of larger amounts of data, such as that used for printers or scanners. Bulk data is sequential. Reliable exchange of data is ensured at the hardware level by using error detection in hardware and invoking a limited number of retries in hardware. Also, the bandwidth taken up by bulk data can vary, depending on other bus activities.    (3) Interrupt Data Transfers: Interrupt data typically consists of event notification, characters, or coordinates that are organized as one or more bytes. An example of interrupt data is the coordinates from a pointing device. Although an explicit timing rate is not required, interactive data may have response time bounds that the USB must support.    (4) Isochronous Data Transfers: Isochronous data is continuous and real-time in creation, delivery, and consumption. Timing-related information is implied by the steady rate at which isochronous data is received and transferred. Isochronous data must be delivered at the rate received to maintain its timing. In addition to delivery rate, isochronous data may also be sensitive to delivery delays. For isochronous pipes, the bandwidth required is typically based upon the sampling characteristics of the associated function. The latency required is related to the buffering available at each endpoint.
USB bandwidth is allocated among pipes. The USB allocates bandwidth for some pipes when a pipe is established. USB devices are required to provide some buffering of data. It is assumed that USB devices requiring more bandwidth are capable of providing larger buffers. The USB's bandwidth capacity can be allocated among many different data streams. This allows a wide range of devices to be attached to the USB. Further, different device bit rates, with a wide dynamic range, can be concurrently supported.